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Formal Verification of an MMU and MMU Cache 

E. T. Schubert 
Division of Computer Science 
University of California, Davis 

Abstract - We describe the formal verification of a hardware subsystem consist- 
ing of a memory management unit and a cache. These devices are verified in- 
dependently and then shown to interact correctly when composed. The MMU 
authorizes memory requests and translate virtual addresses to real addresses. 
The cache improves performance by maintaining a LRU list from the memory 
resident segment table. 

1 Introduction 

Computers are being used in areas where no affordable level of testing is adequate. Safety 
and life critical systems must find a replacement for exhaustive testing to guarantee their 
correctness. Through a mathematical proof, hardware verification can formally demon- 
strate that a design satisfies its specification. However, hardware verification research has 
focused on device verification and has largely ignored system composition verification [1]. 

Our research is directed towards developing a methodology to verify a hardware base for 
a safety critical system. The top level hardware specification is apt to suggest a unitary 
implementation. This abstraction is convenient for verifying the correctness of software, 
however, the implementation consists of many different interacting components (CPU, 
memory, coprocessors, I/O devices, bus controllers, interrupt controllers, etc). This paper 
will describe our efforts to verify a subsystem consisting of a MMU and its cache using the 
HOL theorem prover [2]. 

The abstract MMU reported in [3] assumed a memory model where a read request was 
satisfied in one cycle. We extend the MMU to interact with an asynchronous memory. 
Additionally, the memory is more fully described; providing read and write functions. 
These changes required several significant changes to the abstract MMU proof script. The 
original proof strategy took advantage of the single cycle response time. The new strategy 
must use two arbitrary contents to define when memory words are returned from the 
memory-cache subsystem. 

1.1 Related Work 

Hardware verification requires that the design of a system is formally shown to satisfy 
its specification through a mathematical proof. Using theorem proving techniques, an 
expression describing the behavior of a device is proven to be equivalent in some sense 
to an expression describing the implementation structure of the device. These expressions 
concisely describe the behavior of devices in an unambiguous way. An additional benefit of 
hardware verification is that the behavioral semantics of the hardware are clearly defined. 
This provides an accurate basis for building correct software systems [5]. 
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Hardware verification efforts thus far have focused primarily on a microprocessor as 
the base for computer systems [6], [7], [8], [9], The processors verified have modeled small 
instruction sets and generally, have not included modern CPU features such as pipelines, 
multiple functional units and Hardware interrupt support. Tamarack-3 [9] and AVM-1 [10] 
do provide sufficient interrupt support to connect with an interrupt controller. However, no 
system currently verified provides the memory management functions necessary to support 

a secure operating syste m. _____ r _ ____ __ 

Previous efforts to verify systems have constructed vertically verified systems with a 
microprocessor/memory as the system’s base [11], [5], [1]. These efforts have aimed at il- 
lustrating how hardware verification can be used to close the semantic gap between high 
level languages and the computer^ instruction set. However, the base for these systems (a 
microprocessor-memory pair) has been an unrealistic hardware platform. 

1.2 HOL 

The object language of HOL is a formulation of higher-order logic. Universally quantified 
variables are used to specify input and output device lines while internal device lines are 
existentially quantified. Conditional expressions are in the form: cond —>t hen-clause I 

else-clause. . • --- .. . - - . : : £ _- r 

HOL provides the human verifier with a selection of tactics for use in goal-directed 
proofs. The tactics are very similar to the kinds of steps a human theorem prover would 
take in solving a goal. New tactics can be written that allow the theorem prover to be 
extended and customized for a particular task. New theorems can only be created in 
a controlled manner. All proofs can be reduced to one containing only the 8 primitive 
inference rules and 5 primitive axioms. High-level inference rules and tactics derived from 
some combination of primitive inference rules. 

The following HOL expression defines an and gate implementation using an inverter 
and a nand gate. The existentially quantified variable p, represents an internal fine which 
links the output of the nand gate with the input of the inverter. 
b^andGate a b out - Bp.nand a b p A inv p out 


2 Memory Management Unit 


[12] describes a number of memory management units which form a complexity hierarchy. 
By developing a sophisticated MMU in steps, the construction of the final proof appears 
to be more tractable. The simpler devices validate access to fixed length memory pages 
while the more complex devices authorize read, write or execute access to variable length 


segments and translate virtual addresses to real addresses. Many of these devices were 
designed and verified to the gate level. However, as the complexity increases, the emphasis 
of the verification shifts from gate level connections to the correctness of the operating 
system support features. 

The device described below validates memory requests based on information maintained 
in a memory resident segment descriptor table. The location of the table is determined by a 
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segment table pointer register which is accessible only during supervisor operations. Each 
descriptor consists of two words: the first contains access control information (present bit, 
read/ write/execute permissions, segment size) and the second serves as the base address 
for the segment’s real location in memory. To translate from a virtual address to a real 
address, the MMU adds the segment offset to the segment base address. The MMU assumes 
the table provides an entry for all possible segment descriptors. 

A generic theory for a class of MMU devices is defined where several functions and 
data types are left abstract. Using an abstract representation, details such as word length, 
can be omitted and the verification focuses only on the correctness of higher level abstrac- 
tion (e.g. electronic block level rather than gate level). At a later point, the abstract 
representation can be instantiated with components that implement concrete behavior. 

Support for generic or abstract theories is not directly provided by HOL. However, 
a theory about abstract representations can be defined in the object language [10]. An 
abstract representation contains a set of uninterpreted constants, types, abstract operations 
and a set of abstract objects. The semantics of the abstract representation is unspecified. 
Inside the theory, we do not know what the objects and operations mean. The abstract 
theory package also creates a set of selector functions [11] to extract desired functions from 
an abstract representation. 

The abstract MMU representation generalizes traits particular to concrete implemen- 
tations. Properties such as the the exact security policy and division of a virtual address 
into a segment identifier and offset (as well as the overall number of bits in an address), 
are hidden by functions which given an address, return the segment identifier or segment 
offset field (segld and segOfs, respectively). There is also a function segldshf which 
returns the offset of a segment descriptor within the memory resident segment table for 
a given address. Since descriptors require two words, the implementation of this function 
simply shifts the segment identifier to the left one bit position (e.g. it adds a trailing zero 
bit). 

The abstract functions selected by availBit, readBit, writeBit and execBit extract 
a bit value from an argument of type *wordn . These functions are applied to the first word 
of a segment descriptor. 

Several functions which operate on two-tuples are available. Given a pair of *wordn 
values, add returns a value of *wordn. Functions addrEq, of sLEq and validAccess replace 
the bitVector comparison units defined for the more concrete units. 

Additional abstract coercion functions are available to convert values between types. If 
the theory were instantiated, the abstract types would likely be implemented with bitVec- 
tors; leaving these functions unnecessary. 

Memory is also treated abstractly. The abstract representation provides a fetch function 
fetch. 
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let nunu_ab6 3 new„abstract_representation 


(‘segld*, " : (* address -> *wordn)" ) 
(‘segOfs*, ":(*address -> *wordn)" ) 
('segldshf*, ":(*address -> *wordn)" ) 
(‘availBit* , ":(*wordn -> bool)" ) 
(‘readBit*, ":(*wordn -> bool)" ) 
( ‘writeBit * , ":(*wordn -> bool)" ) 
(‘execBit*, ":(*wordn -> bool)" ) 
(‘add*, ":(*wordn # *aordn ->*wordn)" ) 
(‘addrEq*, " :(*address # *address -> bool)" ) 
(‘ofsLEq* , ":(*address # *wordn -> bool)" ) 


":(*address # *wordn # RHE -> bool)") 
(*val‘, " :(*wordn -> num)" ) 
(*wordn‘, " :(num-> *wordn)" ) 
('address', ":(*wordn -> *address)" ) 
(‘fetch*, ":(*memory # * address) -> *wordn") 



A type abbreviation RWE is also defined to be a three tuple of bit values. Selector 
functions rBIT, wBIT and eBIT access the first, second and third bits, respectively. 


2.1 Specification 

The specification is decomposed into several rules and ignores timing characteristics. The 
state and output environment of the MMU specification is a three-tuple consisting of a 
boolean acknowledgment, a memory address and the table pointer register value. The 
variable r in the definitions below is the abstract representation. 

Functions superMode and userMode describe the behavior of the MMU when operating 
in their respective modes^ legalAccess uses many of the abstract func tio ns to fetch 
from memory the appropriate segment descriptor and compare it with the request’s access 
parameters. vToR constructs a real address from a virtual address. 


b*/ legalAccess r vAddr tblPtr rwe mem = let a = (fetch r)(mem, (address r)((add r) (segldshf r 
vAddr,tblPtr))) in ((validAccess r) (vAddr, a, rwe) A (ofsLEq r) (vAddr, a)) 

•“Je/vToR r vAddr tblPtr mem = let a = (fetch r) (mem, (address r)((add r)((wordn r 1), (add 
r)( se gldshf r vAddr, tblPtr)))) in (address r) ((add r) (segOfs r vAddr, a)) 

b^/superMode r vAddr rwe tblPtrADDR tblPtr data mem = ((wBIT rwe) A (addrEq r 
(vAddr, tblPtrADDR))) -»( T, vAddr, data ) — ( T, vAddr, tblPtr ) 

b j t /userMode r vAddr rwe tblPtrADDR tblPtr data mem = legalAccess r vAddr tblPtr rwe 
mem ->( T, (vToR r vAddr tblPtr mem), tblPtr ) — ( F, vAddr, tblPtr ) 

b j c /mmu_spec r vAddr rwe tblPtrADDR tblPtr data mem superv = superv -•+ superMode r 
vAddr rwe tblPtrADDR tblPtr data mem — userMode r vAddr rwe tblPtrADDR tblPtr data mem 


nii'liilli: II NIT 1 1 I llll ' II? M 'I I in I in i ill 1 ill ill fill i I ill n ill 
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2.2 Implementation 

The implementation is constructed from electronic block model components. These are 
defined as specifications for the behavior of a gate level implementation. Many of the 
devices specify their timing behavior as well. The building blocks consist of a security 
comparison unit, an address match unit, a memory fetch unit, an adder, registers, latches, 
muxes, and a control unit. Most of the device definitions are straight forward with the 
exception of the memory and the control unit. These two units will be described in greater 

detail. 


h 


d'l 


\~d'} 

b def 
b def 

b^/ 

b def 

bit/ 


secUnit.spec r a b rwe ok - V t. ok (t+1) ... 

((validAccess r) ((a t),(b t),(rwe t)) A (ofsLEq r) C Ca t) , Cto t> ) ) 
addUnit.spoc r a b c = V t:num. c (t+l) - (add r ( (a t),(b t) )) 

muxUnit.spec r a b out w =V t . (out(t+l)) = (w(t+l))^ address r(b(t+l))l(a t) 

mux3Unit_spec a b c out w = V t:num. 

(out t) = (w t = 0) — * at I (w t = 1) — * b t I c t 
splitUnit.spec r virt id ofs = V t:num. 

((id t) = (segldshf r) (virt t)) A ((ofs t) * (segOfs r) (virt t)) 
latchUnit.spec r i out Ctrl = V t:num. 

out (t+l) = Ctrl (t+l) -» out t I (i (t+l)) 
regUnit.spec r i Id clr out = . 

(V t:num. out(t+l)=(clr t~* (wordn r 0 ) | Id t -> i t | out t)) 

A (out 0 = (wordn r 0) ) . , , . \ \ t nn 

mat chUnit. spec r a b m = V (t:num). m(t+l) = (addrEq r (a t, b t)) -+ T 1 F 


Memory Unit > 

As a first step towards composing devices, the memory specification used for the MMU 

verification is significantly expanded from the model used in [3]. The earlier model assumed 
a read-only memory that returned a value one clock cycle after a request was made. The 
new model defines asynchronous read and write operations. This model makes an implicit 
assumption that each memory request is satisfied before the next request is generated. 
Most of the new proof effort centered on establishing the correctness of the MMU control 
unit with the new memory specification. 


b de j memoryUnit.spec r req rwe addr data don© mem = 

(done 0 = F) A 
(V t. (req t) — ► 

(3 t'. Next done (t, t+t 1 ) A 

(wBIT (rwe t) => . . . . 

( (mem (t+t J ) = store r (mem t,addr t,data t; ; ; I 
( (data (t+t 1 ) = letch r (mem t,addr t) ) A 
(mem (t+t*) = mem t) ) ) ) 

( (done (t+l) = F) A 

(mem (t + l) = mem t) ) ) 


Control Unit 

To process each memory request, the control unit will pass through several clocked 
phases. At each clock tick the control unit may change its phase depending on the results 
computed by the other internal units and the MMU input from the system bus. The control 
unit state is maintained by the variable phase. There are six distinct phases, however, 
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not all phases are executed for each request. Which phases are executed depends on the 
validity of the memory request. Request evaluation begins with the control unit in phase 
0 and completes when phase 0 is again reached. A valid request will require five phases 
with a delay of at least one time unit before each phase change. 
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Figure 1: Abstract MMU Internal Block Diagram 

The dataPath definition describes the interconnection between all the units other than 
the control unit. 


I~def dataPath 


3 (muxl mux2 id 

CregUnit^spec 

(regUnit^spec 

(secUnit.spec 

(splitUnit_spec 

( mux 3Un i t““sp e c 

(mux3Unit_spec 

(addUnit.spec 

(latchUnit_spec 

(mat chUnit. spec 

(muxUnit.spec 

(memoryUnit _ spe c 


r vAddr vData rwe mem tblPtrADDR tblPtr rAddr muxC 
tmpC tblC 1C rReq xlat match secOK fdone = 
ofs addOut data latOut secData. 
r vData tblC bitFalse tblPtr) A 
r data tmpC bitFalse secData) A 
r vAddi^ secData rwe secOK) A 
r vAddr id ofs) A 

id ofs (oneUnit _spec r) muxl muxC) 
tblPtr data latOut mux2 muxC) 


r muxl mux 2 addOut) A 
r addOut latOut 1C) A 
r vAddr tblPtrADDR match) A 
r vAddr latOut rAddr xlat) A 
r rReq rAddr data fdone mem) 


A 

A 


The implementation definition connects the datapath with the control unit. The state 
consists of the table pointer register value, the security Data register and the control unit 
phase (tblPtr, secData, phase). The input environment is provided by the system bus 
and the memory (vAddr, vData, rwe, superv, reqln, mem). The output environment 
includes a real address and several control unit outputs (rAddr, done, ack, xlat ). The 
memory address of the table pointer register is specified by the constant tblPtrADDR. 
Correctness Statement 

Several auxiliary definitions are used to express the final correctness statement. To 
relate the implementation to the specification, a temporal abstraction is constructed using 
the two predicates Next and First [9]. The predicate First is true when its argument t is 
the first time that g is true. The predicate Next is true when t2 is the next time after tl 
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hjc/ controlUnit_spec reqln super rue match secOK fdone muxC tmpC tblC 

1C rReq xlat done ack phase = 

( (muxC 0 , tmpC O.tblC 0,1C O.rReq 0,xlat 0,done O.ack 0, phase 
0)=(0,F,F,F,F,F,F,F,0)) 


A 

(V 


. (muxC(t+l) ,tmpC(t+l) ,tblC(t+l) , lC(t+l) ,rReq(t+l) ,xlat(t+l) ,done(t+l) , 
ack(t + l) ,phase(t + l) ) = XMttlrxdaP/, 


(phase t = 0) — > (reqln t — > 

(phase t - 1) — * (super t -> 

( (wBIT (rwe t)) A match t) 


((phase t 
((phase t 


t = 
t = 


= 2 ) 

= 3) 

4) - 

5) - 


A 

A 


fdone t) 
fdone t) 


(phase 
(phase 

(muxC t.tmpC t.tblC t,lC t, F 


'/, U m b a e 1 o c H % 

V. I pit q t n k i '/. 

( 0, F.F.F, F.F.F.F, 1) I 
( 0, F,F,F, F.F.F.F, 0)) I 


( 0, F,T,F, F.F.F.F, 5) 

( 0, P.F.F. F.F.T.T ,0) 

( 2, T.F.T, T.T.F.F, 2)) 
•> ( 1, F.F.F, T.T.F.F, 3) 

-► (secOK t -v ( 0, F,F,F, F.T.F.F. 4) 

( 0, F,F,F, F.F.T.F, 0)) 
( 0, F.F.T, F.T.T.T, 0) 

( 0, F.F.F , F.F.T.T ,0) 

, xlat t.done t.ack t, phase t)) 


that g is true. The predicate stable.sigs states that between tl and t2 the MMU inputs 
will remain constant. 

I ~i t j First g t = (V p:time . p<t => -i(g p)) A (g t) 
h rfe/ Hext g (tl ,t2) = (tl<t2) A 

(V t:time . tl<t A t<t2 => -i (g t)) A (g t2) 

I - it j stable_sigs tl t2 vAddr rwe tblPtrADDR data 

mem super = V t 1 . tl < t’ A t * < t2 => 

(super t’ = super tl) A (vAddr t’ = vAddr tl) A (rue t’ * rwe tl) A 
(data t’ = data tl) A (tblPtrADDR t’ = tblPtrADDR tl) A (mem t> = mem tl) 

The correctness theorem states that if the implementation is in phase 0 and a memory 
request is made, the implementation will eventually respond (c time steps later), when 
the state of the implementation matches the state defined by the specification for a set of 
given MMU inputs. The inputs must remain stable until the MMU responds to a request. 
If a memory request is not made, the acknowledgment line remains F , the phase remains 
0 and the MMU table pointer register remains unchanged. 


h numi.imp r vAddr vData rwe super tblPtr tblPtrADDR 
reqln rAddr done ack xlat mem phase => 
(V t. (phase t = 0) => 

(reqln t — ► 

(3 c. Next done(t,t + c) A (phase(t + c)=0) A 
(stable_sigs t (t + c) vAddr rwe tblPtrADDR 
vData mem super => 

(mmu_spec r (vAddr t) (rwe t) (tblPtrADDR t) 

(tblPtr t) (vData t) (mem t) (super t) 
= ack(t + c),rAddr(t + c),tblPtr(t + c)))) 

| ( (ack(t + 1) = F) A 
(phase(t + 1) = 0) A 
(tblPtr (t + 1) = tblPtr t) ) )) 
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3 Memory Subsystem 

An initial design integrated a FIFO cache stack inside the MMU but here we model a fully 
associative cache as part of the memory subsystem. The cache is described as a lookup 
table and implements a least recently used (LRU) replacement strategy. Each table entry 
consists of a key, a related data word, and a boolean indicating whether the entry is active. 
We will first describe the specification of the LRU replacement strategy in HOL, followed 
by the cache implementation. 


TAB.ENTRY * ” sbooli+addressJf+wordn 11 : type 
TAB * M : (~TAB.ENTRY)list rr : iff§ “ 

bd e / live entry » _ (FST entry) 

\~i t j key entry = (FST (SND entry)) 

b A t j content entry = (SND (SND entry)) 


Several auxiliary (recursive) definitions describe table operations below. When an entry 
is inserted into the top of table, the entry at the bottom will be lost only when the table 
is “full ’ 5 (all entries are live). In this respect, the table acts as a queue. 


\~dtf (TAB. FULL tbl 0 = live (EL 0 tbl)) A _ ^ 1 

(fAB.fULL tbl (SUC nj = Clive' (EL (SUC n) tbl) A TAB. FULL tbl n)) f 

\~d t f (TAB. INSERT tbl entry 0 = [entry!) A 

(TAB. INSERT tbl entry (SUC n) = (APPEND (TAB. INSERT tbl entry n) 

((TAB.FULL tbl n) -> [(EL n tbl)] | [(EL (SUC n) tbl)]) ) ) 


A table lookup is successful if there is a key match for one of the entries. For a table 
size of n, TAB_HIT returns (SUC n) if the lookup fails. 

KEY. HATCH rep tbl sg: ♦address n = 

(live (EL n tbi) A ((addrEq rep) (key (EL n tbl) , sg) ) ) 
b dtf (TAB.HIT rep tbl sg in 0 = 

((KEY. HATCH rep tbl sg 0) 0 | (SUC m))) A 

(TAB .FIT rep tbl sg ra (SUC n) = 

((KEY. MATCH rep tbl sg (SUC n)) (SUC n) I TAB.HIT rep tbl sg m n)) 


Frequently, a single matched entry must be invalidated. This can occur due to the LRU 
policy or a memory write operation. Occasionally, the entire cache must be inYyldated at 
the request of the operating system. The LRU policy requires that if a key match occurs, 
the entry be inserted at the top of the table. By invalidating the matched entry before 
the insertion, a table overflow will not occur. LRU_L00KUP returns the requested data value 
and the updated cache table. 


ill III ,1 lllilllULilillN i 
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hj'f ENTRY INVALIDATE entry = (F ,key entry, content entry) 
h de/ (TAB.INVALIDATE tbl 0 = [(ENTRY. INVALIDATE (EL 0 tbl))] ) A 

(TAB.INVALIDATE tbl (SUC n) = ..... 

(APPEND (TAB.INVALIDATE tbl n) [(ENTRY.INVALIDATE (EL (SUC n) tbl))])) 

hjw (DEL.TAB.ENTRY rep tbl sg 0 = ... , 

( (KEY.MATCH rep tbl sg 0) - [(ENTRY.INVALIDATE (EL 0 tbl))] I 

[(EL 0 tbl)] )) A 

(DEL.TAB.ENTRY rep tbl sg (SUC n) = 

(APPEND (DEL.TAB.ENTRY rep tbl sg n) 

((KEY.MATCH rep tbl sg (SUC n)) 

[(ENTRY.INVALIDATE (EL (SUC n) tbl))] 

| [(EL (SUC n) tbl)] ))) 


I ~ it} 
I ~ it] 


LRU.REPL rep tbl entry n = TAB.INSERT (DEL.TAB.ENTRY rep tbl (key entry) n) 
entry n 

LRU.LOOKUP rep mem tbl n addr data newTbl = 
let who = (TAB .HIT rep tbl addr n n) in 
((who = (SUC n)) 

— > ( data = fetch rep( mem, addr) A 

newTbl = TAB.INSERT tbl (T, addr, (fetch rep(mem.addr) )) n ) 

| (data ■ (content (EL who tbl) A 

newTbl = LRU.REPL rep tbl (EL who tbl) n) 


Using the above definitions, the cache-memory subsystem can be defined. This defini- 
tion replaces memoryUnit.spec in the MMU specification and the new system is verified 
in a similar manner. The proof shows that the cache/memory system is consitent with the 
MMU memory model requirements. 


I- 


d'f 


cache .mem.spec r req rwe addr data done mem tbl n 

(done 0 = F) A 
(V t. (req t) -+ 

(] t’. Next done (t, t+t’) A 
(wBIT (rwe t) => 

( (mem (t+t’) = store r (mem t.addr t.data t; 

(tbl (t+t’) = DEL.TAB.ENTRY r (tbl t) (addr t) n ) 

( LRU LOOKUP r (mem t) (tbl t) n (addr t) 

(data (t+t’)) (tbl (t+t»)) ) A 
(mem (t+t’) = mem t) ) ) ) 


) A 


( (done (t+1) = F) A 

(mem (t+1) = mem t) A 
(tbl (t+1) - tbl t) ) ) 


Cache Implementation 

The cache implementation consists of a control unit and a stack of cache cells. Cache 
cells are the instantiation of the table entries described above— their state consisting of 
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Figure 2: Cache Cell Stack 

the three tuple: (valid, address key, data). The action of each cache cell is defined by a 
two bit function code (req) sent by the cache control unit. The stack is formed by joining 
the outputs of a cache unit to the inputs of the next. 


bje/ (cache.block r state req sparceln f oundln addr replState dataln 0 * 

cache_cell rep 0 req addr replState (state, sparceln, f oundln, dataln)) 

(cache.block rep state req sparceln foundln addr replState dataln (SUC n) = 
(cache.cell rep (SUC n) req addr (EL n state) 

(cache.block rep state req sparceln foundln addr replState dataln n))) 


\~itf cache. cell.spec rep n req addr replState (stateln, sparceln, foundln, dataln) = 
let state = (EL n stateln) in 

let match = ( addrEq rep(addr,key state) A live state ) in 
(req = (F,F)) -4 */, IDLE 7, 

(stateln, foundln, (sparceln V 'live state), dataln ) I 

(req = (F,T) ) — % INVALIDATE ON MATCH % 

( ma tch — > 

(SET.EL n stateIn(F,key state , content state), T, T, content state ) | 

(stateln, foundln, (sparceln V 'live state), dataln) ) I 
(req «* (T,F)) —* % INVALIDATE 7, 

(SET.EL n stateIn(F,key state, content state), foundln, T, dataln ) I 
7, req = (T,T) -» PUSHDOWN % 

( sparceln -* 

(stateln, foundln, T, content state ) | 

(SET.EL n stateln replState, foundln, F, dataln) ) 

When a memory request is made, the control unit signals each cache cell to invalidate 
its entry if its key matches the input address (F,T). Memory write requests are also passed 
through to memory. If a read request is pending and the value is not in the cache, the 
value is fetched from memory. We assume one clock cycle is needed to read a value out of 
the cache if it is available. After the value fetch step is completed, the control unit pushes 
the new value onto the cache cell stack by issuing request (T,T). 
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To model memory, the cache implementation uses the same memory unit specification 
(memoryUnit_spec) stated previously. We then verify that the implementation behaves 
as specified. The implementation also provides a means of invalidating the entire table 
(request (T ,F), however, this function is not present currently in the specification. 

4 Summary 

We have described the formal verification of an MMU and cache/memory subsystem. 
The MMU has been verified to perform correctly with an asynchronous memory model. 
The cache specification defines an LRU replacement policy which is implemented by an 
electronic block level design. The cache is also demonstrated to be consitent with MMU 
memory model requirements. 

It has been convenient to represent the behavior of devices using abstract representa- 
tions. This mechanism allows the verification effort to focus on the correctness of higher 
level abstraction. To verify a more concrete implementation, the abstract representation 
can be instantiated with components that implement concrete behavior. Extending this 
example, we plan to demonstrate how a complete system composed of many devices can 
be shown to correctly implement an abstract system specification. 
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